home *** CD-ROM | disk | FTP | other *** search
/ Shareware Overload Trio 2 / Shareware Overload Trio Volume 2 (Chestnut CD-ROM).ISO / dir33 / stacstat.zip / STACSTAT.TXT
Text File  |  1994-03-22  |  7KB  |  98 lines

  1.   
  2. About ten days ago, a federal jury in L.A. returned a verdict against STAC on a trade-secret claim by Microsoft.  The jury even awarded punitive damages because it considered STAC's actions deliberate.   Since then, STAC's president, Gary Clow, and others have devoted an enormous amount of energy on these forums trying to foster the belief that Microsoft will use this verdict to pursue claims against third-party developers who legitimately use debugging tools to achieve or maintain compatibility with 
  3. Microsoft's operating systems. These statements just aren't true.  Nor are 
  4. STAC's claims that all they did was use a few undocumented calls.  STAC 
  5. disassembled and analyzed a sizable chunk of MS-DOS itself to understand its 
  6. internal design.  Then STAC used that knowledge to write code identical in 
  7. functionality for STAC's own product.  The preloading program copied by STAC 
  8. is one that integrates data compression seamlessly into the internal 
  9. operations of MS-DOS to allow data compression to be performed in a safe, 
  10. easy, and efficient manner.  This had nothing to do with undocumented system 
  11. calls. (STAC did intercept a few internal calls but this was the least 
  12. significant part of our design and not the reason we sued them.)    
  13.  
  14. Information obtained during the discovery phase of the case, through diaries 
  15. and testimony of STAC developers, and confirmed during the trial, shows that 
  16. STAC did not merely analyze the compression integration portion of MS-DOS 6 
  17. but disassembled and copied the design, functionality,  features, and 
  18. processes of more than 3,000 lines of MS-DOS compression integration code.  
  19. (By comparison, the compression technology of DoubleSpace, which STAC sued 
  20. Microsoft over, involved only about 1,500 lines of code.)  
  21.  
  22. At the trial, STAC produced a number of expert witnesses who testified that 
  23. they regularly  "reverse-engineered" other programs, and STAC is using that 
  24. as "proof" that other developers are on his side.  In fact, during 
  25. cross-examination, every one of STAC's witnesses said they defined 
  26. "reverse-engineering" to mean analysis for debugging or compatibility testing 
  27. and not for disassembling and copying someone else's work.  STAC's final 
  28. expert witness, Jim Sesma, a developer not affiliated with STAC, was 
  29. specifically asked whether he had ever reverse-engineered or disassembled 
  30. one of Microsoft's products in order to copy the internal design into another 
  31. product.  His answer: "No, I have not.  That is not the intention of anything 
  32. that I would do."  
  33.  
  34. Our outside expert witness testified that STAC could not have done what it did 
  35. with a simple debugger or usual debugging techniques, and that what STAC did 
  36. went far beyond what anyone in the industry would consider necessary for 
  37. compatibility.  In fact, STAC's existing product was already compatible with 
  38. MS-DOS 6, and evidence was presented at trial showing that STAC had other 
  39. technical avenues for preloading that would not require STAC to disassemble 
  40. and copy Microsoft's designs.   For example, IIT's XtraDrive product replaces 
  41. the boot sector with its own code that loads their driver into memory before 
  42. loading IO.SYS, so they get a preload effect without having to use Microsoft's 
  43. technology.  Digital Research took still another technical approach to 
  44. integrating disk compression in DR DOS 6. STAC did not need our trade secrets 
  45. to solve its technical problems; taking our intellectual property was merely 
  46. the most expedient way to do so.  
  47.  
  48. Andrew Schulman and one or two other authors have claimed in various public 
  49. forums that Microsoft's compression integration design is not a trade secret 
  50. because it has been documented in at least two books, including Schulman's own 
  51. Undocumented DOS.  Schulman's book, however, documents less than 2 percent of 
  52. the compression integration design.  This provides some understanding of the 
  53. relative amount of weight in the integration design between the overall 
  54. feature set of the program and the few internal operating system calls used.  
  55. Schulman and other authors substantially understate the daunting challenge of 
  56. uncovering and documenting the complete, detailed technical design that would 
  57. be necessary to replicate an entire subsystem within the operating system, 
  58. which is what STAC did.  For example, Schulman has not been able to document 
  59. how MS-DOS 5 (released three years ago) loads itself into high memory, and 
  60. that task is far simpler than the compression integration of DoubleSpace.  
  61. STAC was able to copy Microsoft's work only after a heavy investment in 
  62. developer time (documented in their own diaries) and has been found guilty of 
  63. violating Microsoft trade secrets in doing so.    
  64.  
  65. Note: My comments here are not pointed at Andrew.  What he has done in his 
  66. research, and what he has published in his books and articles, is radically 
  67. different than what STAC has done.
  68.     
  69. Microsoft's system business is predicated on getting a large number of third 
  70. parties,  both big and small, to develop products for our operating systems. 
  71. Through our developer relations efforts, we continue to provide technical 
  72. information to outside vendors and to encourage support third parties to write 
  73. products for our systems. In addition, from time to time, we will likely seek 
  74. to license third-party software technology to incorporate into our operating 
  75. system and application products.  (For MS-DOS 5 and 6, we licensed technology 
  76. from Central Point, Roundup, Helix, Vertisoft, and Quest/Norton.)    
  77.  
  78.  
  79. Microsoft has no interest or intent in pursuing developers doing legitimate 
  80. technical work to build products to run on MS-DOS or Windows.  It is one thing 
  81. to use software tools to analyze an operating system to ensure that 
  82. applications are compatible with it, or to fix bugs in your product that show 
  83. up in low-level interactions in the operating system, or to work around bugs 
  84. in the operating system itself.  It is another thing entirely to disassemble 
  85. the operating system, copy the design of key features, and incorporate them 
  86. into your own product.  Microsoft is not confused about the difference.  The 
  87. developer community should not be confused.  Microsoft will work hard to 
  88. encourage honest developers to build products for our systems, but we will 
  89. absolutely take steps to protect our trade secrets from unscrupulous 
  90. developers who try to rip off our work.  
  91.  
  92. Paul Maritz,  
  93. Senior Vice President, Systems  
  94. Microsoft Corporation  
  95.         
  96.  
  97.  
  98.